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Abstract 

The  use  of  weakest-precondition  predicate  transformers  in  the 
derivation  of  sequential,  process-control  software  is  discussed. 
Only  one  extension  to  Dijksua’s  calculus  for  deriving  ordinary 
sequential  programs  was  found  to  be  necessary;  hmction-valued 
auxiliary  variables.  These  auxiliary  variables  arc  needed  for  reason¬ 
ing  about  states  of  a  physical  process  that  exist  during  program  tran¬ 
sitions. 


1.  Introduction 

For  the  past  few  years,  we  have  been  exploring  the  use  of  assertional 
reasoning  in  the  constniction  of  process-control  software.  Our  intent  was  to 
employ  an  existing  method,  perhaps  with  a  few  extensions,  and  systemati¬ 
cally  derive  process-control  programs  from  specifications.  Use  of  an  existing 
method  had  both  a  scientific  and  a  pragmatic  motivation.  The  scientific 
motivation  was  based  on  our  expectation  that  the  difficulties  we  encountered 
by  using  an  extant  method  would  provide  insights  into  what  distinguishes 
• 
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process-control  programs  from  ordinary  sequential  and  concurrent  programs. 
The  pragmatic  motivation  was  that  extending  a  well  understood  method  was 
likely  to  be  easier  than  developing  a  new  one. 

Our  investigations  have  been  structured  as  a  series  of  experiments. 
Each  experiment  is  based  on  a  simple  process-control  problem  that  (we  feel) 
epitomizes  some  aspect  of  process-control  programming.  We  started  with 
the  simplest  process-control  problem  imaginable — a  sequential  control- 
program  running  on  a  single,  fault-free  processor.  By  reading  sensors  and 
writing  to  actuators,  this  program  controls  an  on-going  physical  process. 
Solving  such  a  problem  requires  reasoning  about  control-program  execution 
times,  something  that  has  long  been  considered  an  integral  part  of  process- 
control  programming.  We  are  well  aware,  however,  that  any  conclusions 
from  this  experiment  would  have  to  be  regarded  as  tentative.  By  considering 
a  sequential  control-program,  problems  arising  due  to  resource  contention  are 
avoided;  and  by  assuming  a  fault-free  processor,  complications  associated 
with  implementing  fault-tolerance  are  being  ignored. 

Simplifying  assumptions  not  withstanding,  our  first  experiment  did 
lead  to  some  insights  about  the  use  of  assertional  reasoning  in  writing 
process-control  programs.  These  insights  are  tlw  subject  of  this  paper.  In 
section  2.  we  describe  extensions  to  Dijkstra’s  weakest-precondition  calculus 
[2]  [3]  that  we  found  necessary  for  deriving  sequential  process-control  pro¬ 
grams.  Section  3  illustrates  the  use  of  these  extensions  and  the  calculus  by 
giving  an  example  derivation  of  a  control  program.  Conclusions  appear  in 
section  4. 

2.  Using  Weakest  Preconditions  with  Physical  Processes 

Process-control  problems  are  often  specified  in  terms  of  restrictions  on 
permissible  states  of  some  physical  system.  By  setting  actuators  to  manipu¬ 
late  the  process  being  controlled,  a  control  program  ensures  that  none  of 
these  proscribed  states  is  ever  entered.  The  actions  of  the  control  program 
are,  therefore,  closely  linked  to  the  state  of  the  physical  process  being  con¬ 
trolled.  Consequently,  when  deriving  a  control  program,  it  is  necessary  to 
reason  about  both  the  program  state  and  the  state  of  the  physical  process 
being  controlled. 

Assertional  methods  for  deriving  programs  are  based  on  manipulating 
logical  formulae,  called  assertions,  that  characterize  sets  of  program  states. 
One  way  to  employ  assertional  methods  in  the  design  of  a  process-control 
program  is  to  augment  the  program  state  space  so  that  it  includes  information 
about  the  state  of  the  physical  process  being  controlled.  Doing  so.  however, 
requires  extending  the  rules  used  to  reason  about  program  execution,  as  fol¬ 
lows. 

(1)  While  a  program  statement  is  executed,  changes  occur  to  the  sute  of 
the  physical  process  being  controlled.  Rules  characterizing  the 
effects  of  program  execution  must  be  modified  to  reflect  these  other 
state  changes. 
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(2)  Statements  whose  execution  involves  interaction  with  sensors  and/or 
actuators  must  be  axiomatized  as  rules  relating  states  before,  during, 
and  after  execution. 

The  remainder  of  this  section  discusses  these  extensions. 

2.1.  Reality  Variables 

The  state  space  of  physical  system  is  usually  defined  by  a  collection  of 
state  component,  each  of  which  is  indexed  by  some  independent  (physical) 
parameters.  For  example,  the  state  of  a  railroad  train  at  a  time  T  can  be 
characterized  by  its  position  X(D.  its  speed  V{T),  and  its  acceleration  A{T). 
Note  that  the  choice  of  time  as  the  independent  parameter  is  arbitrary.  If  its 
velocity  is  always  greater  than  0,  then  a  train  at  position  X  could  equally  well 
be  described  by  time  T{X),  speed  V(X).  and  acceleration  A(X).  As  physicists 
learned  long  ago,  quantities  that  are  convetuent  for  the  task  at  hand  should  be 
selected  as  the  independent  parameters. 

The  state  space  of  a  program  can  be  augmented  to  include  the  state  of  a 
physical  process.  For  each  state  component  Qi.  we  add  to  the  program  state 
space  a  function-valued  program  variable  qi.  called  a  reality  variable.^  Each 
reality  variable  replicates  (in  the  program’s  state  space)  information  about  a 
physical  system  during  program  execution.  Initially,  the  domain  of  a  reality 
variable  will  be  empty;  as  the  independent  parameter  P,  for  Qi  changes, 
the  domain  of  <7,  is  extended  to  include  the  values  over  which  P,  has  ranged. 
Reality  variables  are  entirely  fictional.  They  allow  us  to  describe  and  reason 
about  the  state  of  a  physical  system  by  using  assertions,  but  they  are  not  actu¬ 
ally  maintained  in  memory.  Thus,  they  are  a  form  of  auxiliary  variable  [  1 ). 

In  order  to  define  and  manipulate  expressions  involving  function¬ 
valued  program  variables,  like  reality  variables,  it  will  be  convenient  to  have 
some  notation.  Following  [21,  given  a  function  /  with  domain  dom{f),  the 
function  expression 

if-,  xeD:g{x)) 

is  defined  to  be  a  function  whose  domain  is  dom(f)KjD  and  whose  value  at 
any  point  a  is  g(a)  ifaeD  and  /(a)  otherwise.  As  a  notational  convenience, 
we  define: 

(/■;  xeD-.gix);  xeD':h{x))  =  i(f;  xeD.gix)):  xcD':h(x)) 

And,  in  specifying  domains,  we  use  the  notation  law.,  high  to  denote  the  set 
[a\low^a^Mgh]. 


'in  the  sequel,  we  use  upper-case  identifiers  to  denote  (physical)  state  com¬ 
ponents  and  the  corresponding  lower-case  identifier  to  denote  the  reality  variables 
that  model  these. 
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2.2.  Preserving  the  Fiction:  Updating  Reality  Variables 

The  state  of  a  physical  system  is  changed  by  a  physical  process.  Typi¬ 
cally.  the  changes  can  be  characterized  by  a  set  of  equations  relating  the 
current  values  of  various  state  components  to  their  recent  values.  We  cannot 
expect  a  physical  process  to  update  the  reality  variables  being  used  in  model¬ 
ing  the  state  of  a  physical  system.  And,  since  the  weakest-ptecondition  cal¬ 
culus  is  based  on  the  presumption  that  all  changes  to  the  truth  of  an  assertion 
are  the  result  of  program  execution,  we  have  no  choice  but  to  regard  the  pro¬ 
gram  itself  as  performing  updates  to  reality  variables.  Program  statements 
can  compute  these  updates  by  using  the  equations  that  characterize  the  way 
the  physical  sute  components  change. 

Consider  some  physical  state  component  Q{P)  being  modeled  by  a 
reality  variable  q{p),  and  suppose  that  as  long  as  no  actuator  changes  during 
some  interval  from  P  to  P-t-5,  changes  to  Q  are  characterized  by  the  follow¬ 
ing  continuous  equation. 

(2.1)  QCP+A)  =  J(Q(/»),A)  forO^ASS 

Let  (5)8  denote  a  statement  whose  execution  coincides  with  a  change  of  5  by 
parameter  P.  Then,  execution  of  (5)8  is  equivalent  to  executing  5  and.  as 
part  of  the  same  atomic  action,  changing  p  and  q  in  accordance  with  (2.1). 
This  sute  change  is  modeled  by  a  program  fragment* 

5;  p.q  :=p+5,(q’,  i  e  p  ..p+5:  7iq(p)f  i-p)) 

Using  the  weakest- precondition  predicate  transformers  for  multiple- 
assignment  and  sutement  composition,  we  obuin  the  following  predicate 
transformer  characterization  for  <5)8- 

>vp«5)8.  R) 

=  «H'pdeenitionof 

>v7j(5,  wp(p,  q  :=p-^5.  (<7;  i  €  p  ..p+5:  Tiq(p),  i~p)),  R)) 

=s  nwp  definition  of 

Wp{S,  p  7{q(p\i-p))) 

Notice  that  when  the  independent  parameter  5  in  (5)8  models  the  pas¬ 
sage  of  time,  (5)8  is  a  sutement  that  executes  for  6  seconds.  The  definition 
of  wpi(S)i,  R)  then  asserts  that  after  executing  (5)8  the  current  time  has  been 
incremented  by  5  and  all  other  reality  variables  have  been  updated  as  if  5 
seconds  had  elapsed.  However,  our  characterization  of  (5)8  also  allows  the 
independent  parameter  5  to  be  a  quantity  other  than  time,  making  it  possible 
to  reason  in  the  coordinate  system  best  suited  for  the  problem  at  hand.  Also 
notice  that,  according  to  our  weakest  precondition  characterization  of  (5)8, 
an  ordinary  statement  5  must  be  regarded  as  being  equivalent  to  (5)o.  This  is 
because 

wp({S)o,R)  =  wp{S,R) 
holds,  since  7(q(p),  0)=q(p)  according  to  (2.1). 
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To  illustrate  the  use  of  wp({S)i.  in  an  actual  process-control  pro¬ 
gramming  problem,  suppose  we  are  interested  in  controlling  the  speed  of  a 
railroad  train.  Define  reality  variable  v(jt)  to  be  the  speed  of  the  train  when  it 
is  at  a  given  position  x.  From  Newton’s  Laws  of  Motion,  we  know  that  if  the 
train  does  not  accelerate  during  an  interval  of  5  seconds,  then  reality  variable 
V  can  be  characterized  by  the  following  equation: 

(2.2)  v(x-*-A)  =vix)  forOSA^v(;t)*5 

Thus,  according  to  our  definition  for  yvp((S)s.R).  we  have  the  following 
weakest  precondition  characterization  for  a  statement  <5)5  that  takes  duration 
5  seconds  and  is  executed  while  a  train  is  not  accelerating. 

wpi{S)i,R) 

=  «(2.2)  and  wp  definition  for  {S)s» 

wp(S, 

^Jt+v(x)»8,  (v;  X  ..jt+v(z)*8;  »(*))) 

2.3.  Interacting  with  a  Physical  Process 

To  have  broad  applicability,  a  method  for  reasoning  about  process- 
control  programs  must  not  restrict  the  types  of  sensors  and  actuators  that  it 
can  handle.  Rules  for  reasoning  about  sensors  and  actuators  can  be  derived 
by 

(1)  modeling  interactions  with  sensors  and  actuators  by  statements  that 
read  and  update  reality  variables,  and  then 

(2)  using  the  titles  provided  for  reasoning  about  ordinary  sutements  to 
derive  rules  for  reasoning  about  these  models. 

As  long  as  reality  variables  correctly  model  the  physical  process,  the  result¬ 
ing  rules  will  be  sound  and  can  be  used  to  reason  about  how  a  control  pro¬ 
gram  interacts  with  the  process  it  controls. 

To  illustrate  how  sensors  and  actuators  are  modeled,  we  return  to  rail¬ 
road  control  Consider  an  actuator  go(r)  and  a  sensor  awaU(c).  Executing 
go(r)  causes  the  train  to  accelerate/decelerate  with  some  maximum  constant 
acceleration  ACC  (say)  until  target  speed  t  is  reached:  execution  terminates 
only  when  the  train  reaches  its  target  speed,  await(c).  if  invoked  while  the 
train  is  not  accelerating,  delays  execution  of  a  program  until  the  train  is  at 
location  c} 

Define  Vlen{u,t)  to  be  the  distance  that  a  train  travels  while  it  is 
accelerating  from  a  speed  u  to  target  speed  r. 

Vlen(u,t)  =  \(u^-t^)/i2*ACC)\ 


^If  go(r)  is  the  only  actuator  that  can  cause  acceleration,  then  the  condition  that 
await(c)  is  never  executed  while  the  train  is  accelerating  is  equivalent  to  stipulating 
that  a  train  is  conuoUed  by  a  single  sequential  program. 
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Define  Vaiiu,  t,  x)  to  be  the  speed  of  a  train  after  having  traveled  x  meters, 
0^x^Vlen(u.  t),  from  the  point  at  which  it  started  accelerating  from  speed  u 
to  t: 


Vat(u,  t,  x) 


'^u^+2*x*ACC  tf  u<t 

<  -2*x*ACC  if«>t 
u  if  t=u 


The  effect  of  executing  go(r)  can  be  modeled  as  an  update  to  reality 
variables  x  and  v.  The  value  of  x  is  increased  by  Vlen(v(x),  t)  and  the 
domain  of  v  is  extended  to  include  x  ..x+Vleniv(x),  t): 

go{t):  X.  V  x+Vlen(v(x),  t), 

(v;  le  X  ..  x  +  Vlen(v(x),  t):Vat(v(x),  t,  l-x)) 

This  multi  pie- assignment  statement  model  provides  a  basis  for  calculating 

^p{go(t),R): 

wp(go(t).  R) 

=  «modei  of  go(r)» 

wp(x,v  :=x+Vl£n(v(x),t), 

(v;  lex  ..x-¥Vleniv{x),  t):  Vatfyfx),  t,  l-x)),  R) 

=  «wp  definition  of 

I), (v;  (€  x.,j+VI*»i(v(x),l):Kw(v()t),/,/-z» 

Similarly,  await(c)  can  be  modeled  by  an  alternative  command: 
await(c):  if  Jt^c  a  0<v(x)  — ♦  j:,  v  :ac,  (v;  /e  x  ..c:  v(x))  fi 

Our  model  for  await(c)  updates  reality  variables  x  and  v  if  xic  and  0<v(x) 
hold;  otherwise,  it  delays  forever.  Using  the  weakest  precondition  for  if,  we 
can  calculate  a  weakest  precondition  predicate  transfonner  for  await(c); 

wp(await(c), /?) 

=  «model  of  await(c)» 

>yp(if  x^c  aO<v(x)— V  :=c,  (v;  le  x..c:  v(x))fi. /?) 

=  «Hp  definition  of  if» 

x^c  A  0<v(x) 

a(x$c  aO<v(x)=»wp(x,  V  ;»c,(v;  le  x ..c;  v(x)). R)) 

=  «wp  definition  of  and  predicate  logic* 

X^C  aO<v(x)a/?J;(,;  ,c:,U)) 

3.  An  Example 

Other  than  the  extensiorts  mentioned  above,  the  methodology  of  [2]  and 
[31  for  deriving  ordinary  sequential  programs  can  be  used,  unchanged,  for 
deriving  sequential  process-control  programs.  In  this  section,  we  illustrate 
that  methodology  with  a  simple  railroad-control  problem. 

Railroad  tracks  are  typically  partitioned  into  segments,  called 
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blocks.  Each  block  i,  has  an  associated  starting  location  bi  and  end¬ 
ing  location  b,+i .  where  b,  ,  and  a  range  of  permissible  speeds 
mn,  ..mx,,  where  0^mni<mxi.  Desired  is  a  program  to  control  the 
speed  of  a  point  train^  so  that  it  travels  from  bo  to  b^,  maintaining 
safe  speeds  along  the  way.  Use  go(/)  and  await(c),  as  defined 
above,  for  interactions  between  a  single  sequential  control  program 
and  the  train. 

First,  we  formalize  the  problem.  The  train  has  made  a  safe  passage  from 
location  atob  provided  the  following  holds. 

S(rfe(a.b):  a ..  b^dom(v) 

A  (Vf:  a^l^b: 

The  first  conjuna  of  Safeia,  b)  asserts  that  the  train  has  actually  traveled 
from  a  to  b,  and  the  second  conjunct  asserts  that  the  train's  speed  satisfied 
the  restrictions  associated  with  each  block  it  occupied.  Using  S(rfe{a,  b).  we 
can  specify  the  above  railroad  control  problem  in  terms  of  weakest  precondi¬ 
tions: 

(3.1)  x=bo/\v=(;  bQ:vQ)=iwp<.S.Sirfe{bQ.b^)/^x=bn) 

This  formula  constrains  5  to  be  a  program  that  terminates  with  the  train  at 
location  b^  after  having  traveled  at  safe  speeds  to  get  there,  provided  5  is 
started  with  the  train  at  location  bo  traveling  with  speed  vq.^ 

3.1.  A  First  Try 

Having  formalized  the  specification  for  a  correct  control  program  5.  we 
now  proceed  with  the  derivation.  The  universal  quantifier  in  conjurKt 
Setfeibo,  bn)  of  the  result  assertion  is  a  tip-off  that  5  should  be  structured  as  a 
loop.  Thus,  we  employ  a  standard  hucristic  from  (2] — replacing  a  constant 
by  a  variable — and  derive  a  loop  invariant  from  the  result  assertion.  Replac¬ 
ing  n  in  the  result  assertion  by  a  new  program  variable  h  (for  ’’here")  we  get: 

/:  S<rf€{bo.bit)  A  x=b^^  a  O^h^n 

Since  I  A  h=n  implies  result  assertion  Sctfe(bo,  bm)  a  x=bn.  we  conclude  that 
the  loop  guard  must  be  h^n  (or  something  that  implies  h *n)  and  conjccnire 
that  5  has  the  following  structure; 


^Assuming  a  point  train  is  not  fundamental.  It  merely  simplifies  some  of  the 
derivation  that  follows.  By  using  a  configuration  space  transformation  [4),  the  con¬ 
trol  problem  for  a  length  L  train  can  be  transformed  to  a  control  problem  for  a  point 
train  on  a  track  with  additional  blocks. 

^If  the  conjunct  x=hn  is  omitted  from  the  result  assertion,  then  it  would  he  per¬ 
missible  for  control  program  S  to  terminate  long  after  the  train  had  passed  point  bn- 
We  have  deemed  such  behavior  unacceptable  and  so  our  specification  prohibits  it 
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5:  5,  {/) 

do  h^n —*  {I /\  h^n]  St,  {/}od  {A=nA/) 

{S<rfeibo,b„)] 

Program  5  will  satisfy  its  specification  provided  we  find  statements  5|  and 
52  that  satisfy  the  following  specifications. 

(3.2)  j:=6o  A  v=(;  ijo:vo)  =>  wp(5i  /) 

(3.3)  I  /\  hi^n  ■=^  wpiSi,  1) 

Formula  (3.2)  is  the  specification  for  the  loop  initialization;  (3.3)  is  the 
specification  for  the  loop  body. 

According  to  specification  (3.2),  5i  must  establish  I.  Observe  that  an 
easy  way  to  establish  /  is  by  setting  /i  to  0.  So,  we  use  wp  to  calculate  an 
assertion  that  must  hold  before  executing  A  :=  0  in  order  for  I  to  hold  after¬ 
wards. 

up  (A  ;=0.  /) 

=  «wp  definition  of 

{S<rfe{bQ,  bit)  Ax=b),  A0^A^n)§ 

=  «textual  substitution* 

Sqfeibo,  bo)  a  x=bo 
=  «idefinitionof5i?Ce(a,b))» 

bo€  domiy)  a  mnQ^v(,bQ)^mxQ  a  x=f>o 

Notice  that  x=Ao  v=(:  boivo),  the  antecedent  of  specification  (3.1)  for  5. 
implies  wp(h  :=0, /)  only  if  mno^VQ^mxo.  Thus,  executing  h  :=0  estab¬ 
lishes  the  loop  invariant  only  under  certain  conditions — the  initial  speed  of 
the  train  must  be  safe  for  travel  in  block  bo.  We  identify  this  requirement 
explicitly. 

Assumption  AS  1.  mno^vo<mxo 

In  retrospea.  this  requirement  should  not  be  surprising.  It  is  worth  noting, 
however,  that  this  implicit  assumption  was  exposed  simply  by  adhering  to  a 
rigorous  calculus  in  deriving  the  program.  Including  this  assumption  in  the 
program  we  have  developed  so  far,  we  get; 

5;  {x=AoAv=(;  bo.vQ)^ASl) 

A  :=0  {/:  S{^e{f)Q,bk)  a  x=bn  a  O^h^n) 
do  A^/i  — >  (/ A  A^/i}  Si  {/)od  {A=«a/) 

[S<rfe(bo.  b„)] 

We  now  refine  52,  the  body  of  the  loop.  Based  on  our  choice  of  guard, 
we  know  that  the  loop  will  terminate  when  A  equals  n.  Initially,  A  is  0.  Thus, 
for  52  to  make  progress  towards  termination,  A  must  be  increased;  and  for  52 
to  satisfy  specification  (3.3),  Si  must  reestablish  /.  To  investigate  the  feasi¬ 
bility  of  increasing  A  by  1,  we  calculate  wp(h  ;=  A+l,  /). 
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wp(h  ;=/»  +  !,/) 

=  *wp  definition  of 

(S(rfe{bo,bs)  A  A 
=  «textual  substitution* 

Sqfeibo,  bs-^i)  ^  x=bi,^.x  aOS>i+1S/i 
=  na^b^c  =*  (Sctfeia,  c)  =  (S<^e(a,  b)  a  Scrfe(b,  c)))* 

S(rfe{bQ,bk)  A  Sctfeib),,  b^^i)  a  x=sb*^i  a  0^A  +  15n 

Since  I  /\h^n  holds  at  the  start  of  S^,  we  know  that  the  first  and  last  con- 
juncts  of  wp{h  :=/i  +  l,/)  hold  before  executes.  We  must,  therefore, 
arrange  for  the  remaining  conjuncts  to  hold. 

S<rfe(bit,  ft^+t)  A  x=b*+i 
=  «definition  of  Si^e(u,  b)* 

A  (V/: 

mn,  ^v(/)Smx,)  a  x=bn+i 
=  <r=b*+t  =>bo.bA+icdom(v)» 

(V/:  bk^l^bk^-x'.  bi<,l^bi^\  mni^v(l)^mxi)  a  x=bA+i 
=  «ptedicate  logic* 

(3.4)  (V/:  b*^/<b*+i:  bi^l^bi+i  mni^v(l)^mxi) 

A  max(mnA.mn*+i)^v(bA+,)imin(/nx*.mxA+0  a  x=b**i 

We  consider  the  final  conjuna  first.  It  is  easy  to  establish  this  conjuiKt  by 
executing  await(b;^^.i).  so  we  compute: 

>i7>(awalt(b*+,).  0-4)) 

=  «wp  calculus* 

x^b^^i  A  0<v(x) 

^  (.(yi-  b>,H<bH+\:  =>mn,Sv(/)^mx,) 

A  max(mn*,  m/i*+i)^v(b*+,)^mirt(mxA,  /«*+,) 

•*’=^A  +  l)5i.,,(v.  /«  I  v(*)) 

=  «textual  substitution  and  simplification* 

(3.5)  x^bf,+i  A  0<v(x) 

A  (V/:  bif^l <bi,i.x:  bi^l^bi^.\  =» 

mn,  S  (v;  /ex..  b*^.i :  v(x)X/)  ^  mx,) 

A  max(mnjk,  mn/^4.1) 

^(v;  /e  x  ..bA+,:  v(x))ibk^i) 

Smin(mxA,miA+i) 

Unfortunately,  (3.5)  is  not  implied  by  what  is  known  to  hold  at  the  start  of 
S2,  I  /^h*n.  We  must  therefore  employ  additional  statements  to  transform 
the  state  from  one  satisfying  /  a  to  one  satisfying  (3.5).  The  final  con¬ 
junct  of  (3.5)  can  be  established  by  executing  go(t).  where  x  is  any  speed  that 
is  safe  and  is  attainable  by  accelerating  from  v(b*).  That  is.  x  must  satisfy; 

(3.6)  maxfm/iA,  )SxSmin(mxA.  mxp,^i) 

A  Vlen(vib^),x)^bH^i-bk 
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Nothing  stated  thus  far  implies  that  it  should  be  possible  to  accelerate 
from  any  safe  v(b>,)  to  a  safe  in  at  most  a  distance  of  +  i  -bi,.  and 

so  without  making  further  assumptions  about  speed  constraints,  our  control 
problem  is  unsolvable.  We  have  uncovered  another  hidden  assumption 
required  to  control  a  train: 

Assumption  AS2.  (Vi,  5:  0<i  <n  a  max(/wi,_i.  mn,)^s5min(rru,_i ,  mj:,): 

(3i':  max(mrt,,  mn,+i)^s'Smin(mx,. 
Vlen(s,s')^bi^.i-b,))) 

Henceforth,  we  assume  that  speed  constraints  for  blocks  do  satisfy  AS2.  (It 
is  not  difficult  to  prove  that  any  control  problem  for  which  there  is  a  safe 
path  from  bo  to  b^  can  always  be  reformulated  as  one  with  more  restrictive 
minimum  and  maximum  speeds  satisfying  AS2.) 

A  target  speed  x  satisfying  (3.6)  can  now  be  computed  as  follows. 
First,  due  to  the  definition  of  Vlen(u,  t).  the  set  of  attainable  speeds  s — both 
safe  and  unsafe — starting  from  position  b^  is  characterized  by: 

'4v(bt,)^-2*ACC*(bt,^x-bh)  ^  Vv(b*)^+2MCC*(h/,+i -h*) 

Second,  the  set  of  safe  speeds  s  for  location  b/,+i  is  given  by: 


maxfmn*.  m/t/t+i)  ^  s  5  min(mx/k, /nxjk4.t) 

The  intersection  of  these  sets,  therefore,  is  the  set  of  safe  and  attainable 
speeds;  the  maximum  of  this  intersection  is  the  greatest  safe  speed — time  is 
money  for  a  railroad. 

■c  =  min(Vv(bi,)^+2MCC*(fc*+i-itA),  mx*.  mx*+i) 

Using  this  value  of  t  for  the  target  speed  ensures  that  the  final  conjuna  of 
(3.5)  will  hold. 

The  penultimate  conjunct  of  (3.5)  now  is  implied  by  our  choice  of  x 
and  Scrfe{bo,  bn)-  Thus,  our  only  remaining  obligation  is  the  truth  of  the 
second  conjuna  of  (3.5),  0<v(x).  Recall  that  holds,  by 

assumption.  Thus,  for  all  i,  /nx,  ^0  and  so  successive  values  of  t  are  each 
non-zero.  Provided  vq^O,  we  can  strengthen  the  loop  invariant  to  include 
0 <  v(x)  as  a  conjunct  This  results  in  the  following  program. 
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S:  lx=bo^v=(:  ^q-^o)  ^ -457  a  0<Vo  a /452) 

H  :=0 

{/;  S(rfe(bo,b)t)  a  x=bi,  a  Q^h^n  a  0<v(x)) 
do  /i^n  — >  {/  A 

52:  r  ;=min(j<7rt(v(7>/i)^+2MCC*(6*+i-7j*)), 
mx*.  mxA+i); 

go(0: 

await(6A+i); 
h  :=/j  +  l 
{/) 

od  {7j=/i  A  /] 

(Sq/^Cfto.  ^-1)} 

As  the  final  step  of  the  derivation,  we  delete  references  to  reality  vari¬ 
ables  from  program  statements.  Recall,  reality  variables  are  auxiliary  and. 
therefore,  may  not  affect  program  execution.  The  only  reference  to  a  reality 
variable  from  within  statements  in  the  program  above  is  the  expression  v(h^). 
We  can  maintain  this  value  in  a  program  variable  vel  by  strengthening  the 
loop  invariant  and  adding  assignments  after  each  go  statement.  Making 
these  changes  results  in  the  following  control  program;  it  solves  the  railroad 
control  problem. 

5:  {x=!bo ''=0  A  A57  A  0<V{)  A  AS2) 

h  ;=  0;  vel  ;=  vq 

(/:  Sife(bo,bi,)  a  x=b|^  a  OfSASIn  a  0<v(x) 

A  vel=v(bH)] 
do  — »  (/  a  /jjen} 

Si-  t  :=  min(j<7rf(ve/^+2MCC*(6A+i-6A)), 

mx*.  /nxA+i); 

go(r); 
vel  ;=  r; 
await(6A>i); 
h  :=/i+l 

{/) 

od  {7i=n  A  /) 

[Scrfeljbo,  6,)} 

3.2.  An  Improved  Control  Program 

Although  correct,  the  control  program  just  derived  does  not  always  per¬ 
mit  a  train  to  travel  as  quickly  as  possible.  Modifying  the  derivation  to  max¬ 
imize  train  speed  is  not  difficult,  however.  First,  we  rewrite  (3.4)  as  follows: 

(V/  b),<l<b^^\:  b,il^bn.\  ^  mniiv(l)imx,) 

A  max(mnji_i . m/i;^)^v(6A)Smin(mx*_i, Anx/^) 

A  max(mn^,  mni,^.i)^v(bh^i)^min{mxf,,  nuh+i)  a  x=6a+i 

Then,  rather  than  allowing  the  final  conjunct  to  drive  the  derivation  (as  it  did 
above),  we  concentrate  on  the  penultimate  conjunct.  The  loop  body  that 
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results  from  this  strategy  is: 

52:  go(fi); 

await(fe*+i-Wert(r,.  :2)); 
go(r2): 

h  :=/i  +  l 

where  rj  and  ti  are  the  largest  speeds  satisfying: 

We/i(v(fe^),  r2)^**+i-** 

Computing  values  for  rj  and  ti  and  using  this  new  52  as  a  loop  body,  we  get 
the  following  revised  control  program. 

5:  {j:=6o^v=(;  6o:vo)  a  A5/ a  0<vo  Ai452} 
h  :=0;  vel  :=vq 

(/:  SafeibQ,bk)  a  x=bk  a  a  0<v(x) 

A  ve/=v(6*)} 
do  /t^rt  -4  (/  A  A^rt} 

52:  ti  :=min(mx/,. 

sqrt(vel^+2*ACC*ibh^^\ -b/,)), 

mxk+i  vgl^ 

sqrt{—^-^-~-^ACC*{bH^x-b,))y, 

t2  :=min(f,.mj*+,); 
go(ri); 

await(AA+i  ~Vlen(ti,  tz)); 
go(t2): 
vel  :st2\ 
h  :=A  +  l 
{/} 

od  (A=n  A  /} 

{S<rfe{bo,b^)} 

4.  Discussion 

We  were  pleased  to  discover  that  oitly  minor  modifications  were 
needed  in  order  to  employ  Dijkstia's  weakest-precondition  calculus  in  deriv¬ 
ing  sequential,  real-time,  process-control  programs.  Dijkstra’s  calculus, 
unfortunately,  is  based  on  regarding  a  program  as  a  relation  between  sets  of 
states  and,  therefore,  does  not  scale-up  to  concurrent  and  distributed  pro¬ 
grams,  which  are  best  thought  of  as  "invariant  maintainers".  The  extensions 
derived  in  section  2  for  handling  the  sute  of  a  {i^ysical  process — the  conui- 
bution  of  this  paper — do  scale  up.  For  example,  we  have  been  able  to  use 
them  along  with  a  logic  for  proving  arbitrary  safety  properties  of  concurrent 
programs.  Proof  Outline  Logic  [5], 

Second,  both  of  the  control  programs  we  developed  assumed  that 
assignment  statements  are  instantaneous.  In  reality,  executing  assignment 
statements  does  take  time,  and  the  state  of  the  controlled  process  can  change 
during  that  interval.  It  is  not  difficult  to  derive  control  programs  for  this 


more  realistic  setting.  The  predicate  logic  details  become  a  bit  messier  as  do 
the  constants,  but  nothing  about  the  structure  of  the  derivation  or  resulting 
programs  changes. 

Reality  variables  are  history  variables — they  encode  in  the  current  pro¬ 
gram  state  information  about  past  system  states.  Using  history  variables  for 
reasoning  about  programs  is  usually  a  bad  idea,  because  it  introduces  distinc¬ 
tions  that  should  be  irrelevant.  The  current  state — not  how  it  was 
computed — should  be  of  concern  when  reasoning  about  what  a  program  will 
do  next.  In  reasoning  about  process-control  systems,  however,  one  has  no 
choice  but  to  employ  history  variables  of  some  sort.  This  is  because  the  past 
instants  for  which  the  state  of  a  physical  process  is  defined  is  a  strict  superset 
of  the  past  instants  for  which  the  state  of  a  control  program  is  defined.  A 
program  implements  a  discrete  transition  system,  while  a  physical  process  is 
likely  to  implement  a  continuous  transition  system.  History  variables  allow 
us  to  reason  about  all  of  the  behavior  of  the  physical  process,  including  those 
states  that  exist  while  the  program  state  is  in  transition,  hence  undefined. 
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